-
Notifications
You must be signed in to change notification settings - Fork 279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ENH: Adds "Min" Method to ProjectionPlot #3940
ENH: Adds "Min" Method to ProjectionPlot #3940
Conversation
…he cookbook and a mwe as 'simple_projection_methods.py' - and it looks like it's working! At least partially :) Addresses Issue #987654321
Hi! Welcome, and thanks for opening this pull request. We have some guidelines for new pull requests, and soon you'll hear back about the results of our tests and continuous integration checks. Thank you for your contribution! |
I love it! Thanks, @rjfarber ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick comment. Note that you also need to somehow conform to code style standards. Our docs (dev guide, code styling) stipulates how.
pre-commit.ci autofix |
@rjfarber I think it needs to be turned on first, but I've asked the bot to do it for you. I think you'll need to pull first before you make any more changes. |
for more information, see https://pre-commit.ci
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More remarks. If you wish to add a deprecation please see the dev guide for how to do it.
…k. Address Issue #987654321
… 'mip' in construction_data_containers. I'm not sure now if I should've done that to clean or left it in there to be safe...
since="4.2", | ||
removal="5.2", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since
refers to the first release this deprecation lands on, so it should be 4.1 (not released yet)removal
is optional and shouldn't be used in general (it's mostly meant for stuff that was deprecated long ago, and that we know we can actually remove soon)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
another important thing is that you should make sure that stack_level
is correctly set so that users will see the actual line they typed in the warning rather than some random line internal to yt that they know nothing about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I updated since to 4.1 and removed removal.
Regarding stack_level
I tried grep -rin "stack_level" from the top level but it didn't return anything. So then I looked at a few other deprecation warnings and it doesn't look like they include it either. So I guess this is a larger issue (?) For example, the deprecation warning for style instead of method in ProjectionPlot is what I copied from...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My mistake, the argument is called stacklevel
. I just tested it and here I think it should be set to stacklevel=4
so we see the line where the YTProj object is created.
It would also be helpful to have a separate deprecation warning closer to users, directly in AxisAlignedProjectionPlot.__init__
, and make sure we don't trigger both warnings at the same time (meaning, AxisAlignedProjectionPlot
should also be able to replace "mip"
with "max"
so the YTProj
object created internally doesn't need to emit a second warning)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't look like stacklevel is being used anywhere so far:
(yt-fork-env) ryanjsfx@MB-145 yt-fork % grep -rin stacklevel .
./yt/_maintenance/deprecation.py:19: msg: str, *, since: str, removal: Optional[str] = None, stacklevel: int = 3
./yt/_maintenance/deprecation.py:50: warnings.warn(msg, VisibleDeprecationWarning, stacklevel=stacklevel)
but okay I set stacklevel=4 (will commit after I get the cookbook working).
Theoretically, should that also be true of the deprecation warning for the use of 'style' instead of 'method' keyword arguments for ProjectionPlot?
====
Regarding AxisAlignedProjectPlot.init triggering the deprecation warning, should that also be true for the style vs method usage then? If so, maybe beyond the scope of this PR...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't look like stacklevel is being used anywhere so far:
this is indeed a problem we'll want to fix globally. I wasn't aware of this, thank you for calling it out !
Theoretically, should that also be true of the deprecation warning for the use of 'style' instead of 'method' keyword arguments for ProjectionPlot?
yes !
Regarding AxisAlignedProjectPlot.init triggering the deprecation warning, should that also be true for the style vs method usage then? If so, maybe beyond the scope of this PR.
Agreed. You don't need to fix these in your PR, but thanks a lot for raising this concern, I'll dedicate a PR to fixing this globally ! However my point about adding a depr to AxisAlignedProjectionPlot
still stands :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay I moved the deprecation warning to AxisAlignedProjectionPlot (which will propagate here once I get pre-commit happy...)
Is class YTProj
guaranteed to inherit from the axis-aligned version of ProjectionPlot though? If not, the deprecation won't trigger.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay I moved the deprecation warning to AxisAlignedProjectionPlot (which will propagate here once I get pre-commit happy...)
There's a slight misunderstanding. I meant that we want two deprecation warnings to exist, not move the one you already had.
Is class YTProj guaranteed to inherit from the axis-aligned version of ProjectionPlot though? If not, the deprecation won't trigger.
So YTProj
doesn't actually inherit anything from these classes, but I think I know what you mean, and indeed the deprecation should also be seen for OffAxisProjectionPlot
so it's best to put it in the base ProjectionPlot
class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sooooo class ProjectionPlot(NormalPlot)
only has a __new__
method (no __init__
) and it's not very clear to me if it takes in method
(maybe as part of *args (?))
I put in the deprecation warning but doesn't look like it fits aesthetically at least 🤔
Nerp it yields an UnboundLocalError method referenced before assignment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this is delicate. Maybe just don't worry about it, I can do it myself once the rest of the PR is ready :)
… it was intended to have. Addresses issue #987654321
custom file name Co-authored-by: Clément Robert <cr52@protonmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note that there a many cookbook example using method="mip"
, you'll want to update them as well so they don't trigger deprecation warnings
…t of little commits since I made a lot of changes and just lost them all :*( Addresses Issue #987654321
…projection method call
I only noticed one 🤔 Anyway I did a |
ok we got the docs build back up. I see that some tests are failing already but let's see what else is broken so we can iterate further.
I can't be the judge of that, but I do want to stress that with IsolatedGalaxy, the recipes takes about 10s, whereas with your preferred dataset it takes about a minute. This is about a 2% overhead on our docs build time, it's far from negligible, which is why I would like if we could find a better compromise. |
I think this is a bit unfair given that the pre-existing most similar cookbook scripts simple_projection.py AND simple_projection_weighted.py both use that same dataset. That's the only reason I started with it in the first place. |
That's fine, I can get behind that, and we can always optimise this later if we actually need to. |
Got a couple failures on CI. Please run the failing tests locally and fix them. Do not hesitate if you have questions or need further help ! |
Okay! Need to do some research this morning but will plan to return to this
in ~8 hours :)
Best,
--------
Ryan
…On Thu, May 26, 2022 at 4:47 PM Clément Robert ***@***.***> wrote:
Got a couple failures on CI. Please run the failing tests locally and fix
them. Do not hesitate if you have questions or need further help !
—
Reply to this email directly, view it on GitHub
<#3940 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGNJQV4NE5AWDWSS3JXSWATVL6FI7ANCNFSM5W5ZTDIQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took a look at failures, here are some pointers for how to solve them
Co-authored-by: Clément Robert <cr52@protonmail.com>
Co-authored-by: Clément Robert <cr52@protonmail.com>
Co-authored-by: Clément Robert <cr52@protonmail.com>
Okay I looked at the failures and think maybe they'll be good now. It looks like the checks are running above so will see if there's a new error to look at. |
Awesome, thank you ! |
@rjfarber one last failure, and it's coming from a test I "helped" with. I'm sorry if I broke it. |
Hooray! Congratulations on your first merged pull request! We hope we keep seeing you around! 🎆 |
Example/which one???
PR Summary
This change is not required. But I found that I wanted to take a minimum projection plot and maximum is already implemented, so why not?
PR Checklist
Okay :)